Field of the Invention
The present invention relates to a method for influencing a control program.
Description of the Background Art
A method for influencing a control unit is known from the document DE 10 2004 027 033 A1, which corresponds to U.S. Pat. No. 8,645,918, which is incorporated herein by reference.
Electronic control units are used for control tasks in numerous complex, technical systems, in particular in motor vehicles. It is a matter of course that a control unit program, hereinafter called control program, usually has a plurality of subroutines, with a typical control program using 10,000 and more control unit variables. By means of the control programs implemented in the control units, actuators such as, e.g., injection nozzles or electric steering systems, are controlled, values are read from sensors such as, e.g., rate of rotation sensors, acceleration sensors, mass airflow sensors, and exhaust gas probes, and the values are evaluated and processed. On account of the potentially safety-critical applications for many control units, very stringent demands are placed on the reliability and freedom from defects of the control program. Accordingly, development is resource-intensive and is carried out with a plurality of test series. It is desirable in this context to change functions of the control program, or at least variables of functions of the control program, at a stage as early as the development and redevelopment or continued development, or testing, of the control units. For this purpose, specific service functions, for example, are known from the conventional art that are configured to deactivate a first function of the control program and replace it with a second, subsequently implemented function, for instance, in that variables written by the first function are subsequently overwritten with the output values of the second function. The calls to the service function can be inserted into the program code either early on, during development of the control program at the so-called source code level, or they are inserted subsequently, after completion of the control program.
Oftentimes, the source code of the control program is not available to function developers and test engineers who wish to make a change to the control program as described above, and who to this end wish to insert a call to a service function, for example, into the control program code after the fact. However, as a general rule, the binary code is available, for example in the form of a hex or srec file, together with the associated control unit description file, for example in the form of an ASAP2 file, for calibration, measurement, and flash programming of the control units. Changing functions of the control program, as described in the previous paragraph, must then be carried out using the binary code of the control program. The developer entrusted with this task is then faced with the problem of identifying the functions to be changed in the binary code. An analysis of the binary code, also referred to as parsing, does indeed make it possible to recognize function calls and the associated memory addresses as such, but the calls cannot readily be assigned to specific functions. In other words: By means of parsing it is possible to determine that a function is stored at a specific memory address, but not which function of the control program is stored there.